As it is generally known, Java programs that are run from a Web browser are known as “applets”. Applets are executed in the Web browser environment using Java plug-in technology. Applets consist of Java executable files that are transferred from a server system and executed within the Web browser on a client machine. In existing systems, the executable files for an applet are Java class files (i.e. files having a *class extension and storing Java byte code) that are bundled into one or more JAR (Java ARchive) files.
When executing an applet for the first time, the plug-in on the client system downloads the applet's JAR files from the server system into its local cache directory, and then renders the applet in the Web browser window of the graphical user interface. A significant drawback in existing systems is the time delay between downloading the applet's JAR files and rendering of the applet. For example, in the context of a typical data communication network, for a JAR file of size of approximately 2 Megabytes, such time delays may approach 5-6 seconds. Delays of this extent are frustrating and time consuming for the user.
Attempts have previously been made to address this problem, but have fallen significantly short in terms of providing an effective solution. One previous approach existing in the Java Plug-in code base from Sun Microsystems provides that the whole JAR file is downloaded before the applet is made visible to the user. The main drawback of this type of approach is still the delay in applet start-up, again resulting in an undesirable delay experienced by the user.
Existing Java Plug-in technology also includes the option of using what is generally known as “lazy” downloading of JAR files. However, in existing systems, the lazy JAR downloading is still performed by downloading a complete JAR file at the time that at least a portion of it is required. Even with such existing “lazy” approaches, the requirement that the whole JAR file be downloaded in its entirety causes significant time delays for the user.
In U.S. Pat. No. 6,636,885, a solution is proposed for delaying the loading of classes that are un-necessary for applet start-up by using interface stubs for the delayed classes. This approach has several shortcomings:                Only single JAR file applets are discussed, and the multiple JAR applet scenario is not dealt with at all.        The delayed classes are downloaded over the network whenever they are referenced. Most applets are interactive, which means that the classes will be downloaded whenever the user actions reference them; as a result there again may still be a freeze or delay requiring the user to wait at applet run-time.        The system presents the user with a false sense of security that the applet is fully up and running, when the delayed classes have actually not been downloaded.        The system has no ability to automatically determine the startup classes for the applet.        
For the above reasons and others, it would be desirable to have a new system for fast rendering of unsigned applet JARs (Java Archives) in a Web browser environment that addresses these problems.